Current design processes for engineered systems have led to the use of sophisticated methods to simulate the behavior of increasingly detailed models. Complexity and a greater level of detail increases the probability that unexpected and undesired behavior is introduced into the model either through modeling error or by the inappropriate use of the simulation/execution environment. For example, large models rely on compositionality principles to manage their size. These models are frequently designed in separate pieces. In some cases, piecing together separately designed, functionally correct parts of a model results in aberrant behavior of the combination. Another example of unexpected and undesired model behavior is a severe slow-down in continuous time simulation due to the repeated use of very small step sizes that may be a result of incorrect or inefficient modeling of an engineered system.
It should be noted that during the discussion contained herein reference is made alternatively to the terms execution and simulation of a model. Those skilled in the art will recognize that block diagrams may be simulated and/or executed, while other types of models in a graphical modeling and execution environment such as state flow diagrams are executed. The term execution as used herein should be understood to also include the simulation of block diagrams.
To identify a cause when a model does not execute as expected, or when its execution time needs to be improved, detailed information about its execution has to be available. Unfortunately, this level of detail is not available as its display and accessibility introduces significant execution overhead. Instead, the model can be run in a distinct ‘debug’ mode, where the additional information is exposed, but at the cost of execution speed.
As an example, FIG. 1 shows a subsystem 1 designed to generate a particular pattern while another subsystem 3 produces a pattern that should be detected and locked when found. These subsystems can be designed independently, but when connected, unexpected behavior may result. In this model, a comparator 5 may fail to produce a logical one at times because the zero-crossing detection of the ‘==’ operator does not ‘step on’ the point in time where the two values are exactly the same. Analyzed in debug mode, the actual values of the input and output of the ‘==’ comparator block for each of the stages of the iterative zero-crossing detection can be studied. This shows that the iteration aborts when the inputs from the generator, U1, and the lock pattern, U2, are
U1=[1.1111111111111276]
U2=[1.1111111111111112]
Because these values are not exactly the same, the output of the comparator produces
Y1=[0].
Since the U1 and U2 values are within the tolerance of the zero-crossing detection mechanism, the exact equality is never achieved and the comparator never produces a logical one. Once the problem is identified, the model may be adjusted. For example, the model in FIG. 1 can be changed to use a dedicated hit-crossing block, crossing in which case the zero-crossing detection is more accurate and the comparison correctly identifies the equal patterns. The need for a sophisticated debug tool becomes even more apparent as the size of the model is increased.
Elements of a block diagram such as blocks, subsystems and the underlying model contain a collection of methods that are invoked by the execution engine at certain times during the simulation for different purposes, e.g., to generate an output, to update the state, and to compute derivatives. Because conventional debuggers expose only a small part of the entire set of methods that have to be invoked by the execution engine in order to execute a block diagram (e.g. the output method of blocks), users are only able to stop the execution of a block diagram at a block's output method and inspect data relevant to a block with respect to its output method. This is a major restriction in debugging a model's execution since the unexpected behavior may not be observable at a block's output method. Instead, the behavior may be related to a non-virtual subsystem method or one of the other types of methods, in which case displaying data at a block's output method is not helpful to the user. For example, the sort of problem illustrated in FIG. 1 could not be analyzed properly using conventional debugging tools in a graphical environment.
An additional drawback to conventional debugging systems is that in addition to stepping to the output method of the next block in a simulation order, the user can only step to the start of the next time step. As a result, the user does not have access to the majority of the computations executed during the simulation loop. Conventional debuggers also do not display the context in which a method is invoked, thus exacerbating the difficulty in analyzing the execution of a model. During one time step in simulation, the execution engine may invoke the output method of a block in various stages, e.g. during the calculation of model states, during calculation of model outputs and during zero-crossing detection. The present state of debugging tools does not allow the showing of any information regarding the context in which a method is executed. Accordingly, when the output method of a block is shown to be invoked, the user is unaware of which stage the simulation is in, and, therefore, the provided information about the output call is less useful.
In current debugging environments, the main graphical element is a graphical view of the block diagram, as designed by the user. As the user steps through an execution in the graphical view of the model, blocks related to the currently executing method may be indicated by a change of color. However, the block diagram as designed by the user may have been modified in a compilation stage before it is simulated. This compilation processes the block diagram by adding or removing non-graphical elements to optimize simulation. Since the debug information is relayed to the user only through the graphical elements of the original (pre-compiled) block diagram, critical simulation information embodied by the compiled version of the block diagram is not revealed to the user. The current type of graphical display generated by debugging tools does not contain any information on why blocks are indicated with a change of color and their relationship to the currently executing method.
Current model views shown during a debugging session do not contain any facilities to superimpose block output/input and internal data such as states, work vectors and derivatives onto the block diagram view. Instead, the user has to go to a command prompt to obtain relevant numerical data of a specific block. Not being able to see the relevant numerical data superimposed on the graphical topology as captured by the block diagram of the model during debugging is a major impediment to efficient debugging.
Conventional debugging methods also do not allow the user to interact with and affect the ongoing model simulation. The user cannot change or inject data into the model to test different scenarios while in a debugging session. Rather, the user first quits the debugging session, sets up the block diagram for a different scenario, and then restarts the debugger in order to test different scenarios.
Another issue with conventional methods of debugging is that it can only be used to debug simulations in interpreted mode. Interpreted mode processes code line by line without compiling it first. The model simulation must be run inside the execution engine. However, many applications of block diagram modeling result in the creation of standalone executables that run a block diagram simulation in a compiled mode of simulation. These executables also need to be debugged. At present, users do not have the capability to debug these standalone executables and see the run-time execution values on the block diagram.